[レポート] パフォーマンスを考慮したアプリケーションの設計 #SnowflakeDB #SnowdayJapan

SNOWDAY JAPAN

#Snowflake

しんや

2023.03.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

2023年02月14日(火)、ANAインターコンチネンタルホテル東京、ならびにオンライン配信のハイブリッド形式でSnowflakeのイベント「SNOWDAY JAPAN」が開催されました。

当エントリではその中で、ブレークアウトセッションとして開催された「パフォーマンスを考慮したアプリケーションの設計」のレポートをお届けします。

セッション概要

当エントリで扱うレポートのセッション概要は以下の通りです。

SNOWDAY JAPAN

[セッションタイトル]
パフォーマンスを考慮したアプリケーションの設計

[登壇者]
・武部祐紀氏(Snowflake株式会社　セールスエンジニアリング本部　シニアセールスエンジニア)

[セッション概要]
このセッションでは、最高のパフォーマンスを実現するためのアプリケーションの設計方法について説明します。トピックとしては、ウェアハウスの適切なサイズ、マルチクラスターウェアハウスでの並行処理、クエリのプルーニング、コンパイル、クライアントの接続と転送の最適化などが含まれます。また、パフォーマンスを向上させた最近の変更点や、より高い同時実行性と低レイテンシーのワークロードをカバーするために活用できる今後の機能についても説明します。

セッションレポート

はじめに

本セッションではパフォーマンスに関する話をSnowflakeのアーキテクチャを紐解きながら紹介。
今後の新機能に関する情報が含まれている。ここに関しては『あくまでも予定』という情報でご了承頂きたい。

アーキテクチャ

アーキテクチャの全体概要
- - データ基盤。所謂OLAPと呼ばれるカテゴリ。OLTPのデータベースでも使われているShared Everythingというアーキテクチャで利用されている
  - 大規模並列処理を基本としたものが既存のアーキテクチャ。
  - Snowflakeはそれらとは異なった、シェアードデータなんだけれどもマルチクラスター、という新しいアーキテクチャになっている。
  - Snowflakeもまた大規模並列処理に対応。クラウドのポイントである『無制限のコンピューティングリソース』『無制限のストレージ』を存分に利用出来る
- - 階層は大きく3つに分かれている：クラウドサービス層/コンピューティングリソース層/ストレージ層　
SQLクエリのライフサイクル：当セッションでは2番目の「PlannerとOptimizerがクエリを処理」3番目の「ウェアハウスでのクエリ処理」について掘り下げる。
- - ネットワークレイテンシは非常に重要。なのでなるべくSnowflake環境から近いところ(同一のクラウドプロバイダや同一のリージョン)でアプリケーションを動かす、というのが基本事項。
  - Snowflake提供のネイティブコネクタを利用
  - 稼働環境における十分なCPUリソースとネットワーク速度の確保
  - Snowflakeは暗号化通信にHTTPSプロトコルを利用：OSCPキャッシュが有効化されていること
  - シンプルなSQLコーディングを検討

クラウドサービス/マイクロパーティション

Snowflakeは「ニアゼロメンテナンス」。基本的には何もしなくてもパフォーマンスが出る。この「マイクロパーティション」という技術がそれを支えている
この仕組み、一度作成されるとその後は更新されない。中身のデータが更新されると新しいマイクロパーティションが作られる
タイムトラベル機能を使うことで昔のマイクロパーティションも見れる、という仕組みになっている
マイクロパーティションについては『半構造化データ』もサポート。JSONやAvro、XML等のデータはVARIANT型でRAWデータのまま取り込みが可能
- 「プルーニング」「フィルタリング」によって構造化データとほぼ同等のパフォーマンスが得られる
Snowflakeにおける「メタデータ」もパーティション単位で作成される
- 列数が多いテーブルの場合、マイクロパーティションの数も増えてしまうしメタデータの数も増えてしまう。結果参照時の時間も掛かってしまいパフォーマンスが落ちる形となってしまう。
- ここに関しては列数を減らす事が最も得策。(フルマネージドな領域なので出来るのはこれくらい) 大福帳テーブルなどでパフォーマンス問題が出て来た場合はこれが有効。
- パーティションプルーニング：Snowflakeが早い、と言われている根拠になっているところ。
- 実際にSQLが実行される際に「必要なデータだけスキャンして持ってくる」仕組み。
- 非常にテーブルサイズが大きくなってきた場合、パフォーマンス課題が出てくる場合がある。その際に使えるのが「クラスタリング」の機能。
  - クラスタリングキーとして実際の列を指定してマイクロパーティションを作り直す。
  - クラスタリングについては「自動クラスタリング」という形で提供している。運用負荷は低い。

クエリプロセッシング/ウェアハウス

ウェアハウスのスケーリング
- 垂直スケーリング：スケールアップ。ウェアハウスのサイズを大きくする/コンピューティングリソースを増やす。1つのSQLが重い処理だった場合に高速化
- 水平スケーリング：スケールアウト。同等の重さのSQLが沢山実行されるような場合に同時リクエスト数の対応数を増やす
ウェアハウスの検討事項
- スケールアクロス：データ分析基盤には様々なリクエストが飛んでいる(これをSnowflakeでは"ワークロード"と呼んでいる)。ワークロード毎に処理の傾向は異なっているので、それぞれの処理毎にそれぞれのウェアハウスを用意して対応している。
データロード/データ更新：Snowflakeはバルクロード、バッチDMLに最適化。COPYコマンドについてはファイル数、ファイルサイズ、ファイルコンテンツが重要。
ウェアハウスのサイズに関するガイドライン
- スキャンされるバイト数が大きくなればなるほど、サイズアップをした方が良い。
- SQLの複雑さ、メモリ使用量も影響。大きいサイズのORDER BY、GROUP BY、JOINをするようなワークロードにもサイズアップは有効。
スケールアウト：マルチクラスターウェアハウスによる同時実行数の対応。階段状にリクエストが増えていくような場合、クラスターを設定するのが有効。
ウェアハウスサイズを決定する際の道のりについて
その他「パフォーマンス向上」における対応策、サービス
今後提供予定の新機能

まとめ

という訳で、SNOWDAY JAPANブレークアウトセッション「パフォーマンスを考慮したアプリケーションの設計」のレポートでした。タイトルにあるように「パフォーマンス」に特化したトピックの紹介セッションとなりましたが、ポイントが押さえられていてとてもわかり易く、今後の参考になる情報が多い内容でした。ここで紹介された情報を含め「Snowflakeのパフォーマンスチューニング、ベストプラクティス」的なものは色々あるかと思いますので、その辺りも学びつつ自らの血肉としていければと思います。